-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarity get/set! when canget/set returns false #210
Conversation
Hmm. I don't think we should allow |
I think that ideally:
This is starting to sound like the |
@tkoolen is there really a need for an unsafe version? If you're iterating over a bunch of |
What would be done in function MOI.safeget(...)
if MOI.canget(...)
MOI.get(...)
else
error(...)
end
end |
@mlubin, I thought that there was a need for that given your earlier comment, JuliaOpt/MathOptInterfaceBridges.jl#87 (comment). If that's not the case, what I proposed is probably unnecessary. @blegat, yep. |
This has been updated to reflect that the call should throw an error. |
### Note | ||
|
||
It is the user's responsibility to check that `canget` returns `true` prior to calling `get`. | ||
Calling `get` when `canget` returns `false` will throw an error. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is now a weird statement. Do we need to add this note for addconstraint!
modifyconstraint!
, etc (anything that as a corresponding canXXX
)?
I would phrase it more of a note for implementations. These functions must throw errors if the corresponding canXXX
returned false.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this just be a general note in the manual then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, could be in the section on notes for solver wrappers.
Closing in favour of #228 |
As raised in #209